Output Filtering（輸出過濾）的概念是 LLM 產生 Response 之後，不一定要立刻把內容送給使用者，而是可以先經過一層安全檢查，如果發現問題就可以選擇把內容遮蔽或是重新產生 Response，甚至直接阻止輸出，上一篇 Input Validation 是檢查輸入的東西，Output Filtering 就是檢查輸出的東西。

最簡單的 Output Filtering，我們一樣直接用 JavaScript 做一個簡單的例子，假設系統不希望 AI 把 Email Address 直接顯示給使用者，可以在 Response 回傳以前先處理：

function filterOutput(output) {
  const emailRegex =
    /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi;

  return output.replace(emailRegex, "[EMAIL REDACTED]");
}

const response = await callLLM(userInput);

const safeResponse = filterOutput(response);

return res.json({
  message: safeResponse
});

假設 AI 原本產生：user@example.com
最後使用者收到的就會變成：[EMAIL REDACTED]
這就是一個非常簡易的 Redaction（遮蔽）。

但 Regex 很快就會遇到極限，Email 還算容易判斷，但如果今天想阻止 AI 洩漏姓名或公司機密等，我們不可能把所有三個字連在一起的詞都當名字，因此實際的 AI Application 通常不會只依賴 Regex，可能會加入專門的 PII Detection（個人識別資訊偵測），例如 Microsoft Presidio 就是一套開源的資料保護工具，可以協助辨識與處理文字中的 PII，可以去他官網看看，他會偵測可疑文字再偵測上下文去找出敏感資料去做到保護個資匿名化的技術。

為什麼這件事很重要?

假設公司有一個內部 AI Assistant，可以搜尋公司的文件，員工可能只是想要取得某個資料，結果因為權限或模型判斷出了問題，Response 裡意外包含 AWS_ACCESS_KEY_ID ，如果系統拿到 LLM Response 就直接顯示，這個 Secret 就暴露了，但如果 Output Filtering 能辨識 API Key、Token 或其他 Secret Pattern，就還有機會在內容真正到達使用者以前把它攔下來，當然最根本的做法還是不要讓模型取得它本來就不需要的 Secret，而不是期待 Output Filter 幫忙擦屁股，這就會牽涉到之前講過的 Least Privilege（最小權限原則）。

不過當然也要知道 Output Filtering 不是萬能的，跟昨天的 Input Validation 一樣，如果規則太嚴格，正常內容可能被誤判；規則太寬鬆，又可能漏掉真正的敏感資訊，而且攻擊者還可能刻意改變資料的表達方式，試圖繞過 Filter，所以真正比較合理的設計仍然是 Defense in Depth，Input 進來以前要檢查，LLM 能存取什麼需要限制，Output 出來以後也再次確認。

Input Validation 與 Output Filtering 可以看成 AI Application 前後兩道很直覺的防線，Input Validation 嘗試降低危險內容進入模型的機會；Output Filtering 則是在模型產生結果後，再確認這些內容是否真的適合交給使用者或其他系統，但如果 AI 本身擁有非常大的權限，那麼就算 Input、Output 都做了檢查，風險依然存在，因此下一篇就要把防線往更底層移。

下一篇：Day 18｜Least Privilege：為什麼 AI 不應該擁有太多權限？